FreeOTFE logo FreeOTFE
Free disk encryption software for PCs and PDAs
(PDA version of WWW site)

Contents

Linux Volumes

PC version only This section applies to the PC version of FreeOTFE only

IMPORTANT: This is obvious, but... If you are using FTP to transfer your Linux volumes between your Linux and MS Windows systems, make sure you transfer the volume file in binary mode!

Creating Linux Volumes

 IMPORTANT: If you select the wrong options when creating a Linux volume using FreeOTFE, you will not be able to read it under Linux! (Although this is patently obvious, there are some people who...!)

NOTE: At time of writing (17th July 2005), although FreeOTFE can read and write LUKS volumes, it cannot create them itself.

To create a new encrypted Linux-compatible volume:
  1. Launch FreeOTFE
  2. If you are creating a file-based volume (as opposed to an encrypted partition):
    1. Select "File | Linux volume | New..."
    2. Enter the filename and size of the volume required.
    3. Click the "OK" button
      4. This will create a file of the appropriate size, and is the equivalent of the Linux command:
      dd if=/dev/zero of=./vol_none bs=1M count=x
      Where "x" is the size of the volume in MB.
      This step is unnecessary in case of using an existing partition on your HDD, and is only required in order to create the file which is to store the encrypted data.
  3. Select "File | Linux volume | Mount..."
  4. Enter the appropriate parameters into the mount dialog.
    See the "Linux Examples" section in the documentation for example configurations; the choices you make here must reflect those options that are supported by the version of Linux you wish to subsequently use the volume with.
  5. Click the "OK" button
    6. This will mount the volume using the encryption system(s) specified, and is analogous to executing the Linux commands:
    losetup /dev/loop0 <volume file> <various options>
    mkdir ./mountpoint
    mount /dev/loop0 ./mountpoint
    At this point a new drive should appear, although at this stage it is unformatted and you will be given an error if you attempt to access it (e.g. using Windows Explorer)
  6. Select the new drive
  7. Select "Tools | Format..."
    You will be shown the standard MS Windows format dialog. It is suggested that you select either the FAT or FAT32 filesystem.

  8. Click "OK" button to format the volume.
    This is analogous to the Linux command:
    9. mkdosfs /dev/loop0
    Your volume file is now fully ready for use, although for security reasons it is highly recommended that you now initialize the volume by writing data to all its sectors before making any further use of it.

    This process is recommended because if omitted it may be possible for an attacker to determine the amount of data you have stored on your volume file (as stated above, the actual process of creating the volume file consists of creating a suitably large file, filled with zeros)
    Note: It is important that this step be carried out if you intend using the volume file just created as a "host" file for storing a second, hidden, encrypted volume.

  9. Switch back to FreeOTFE, and select "Tools | Overwrite free space..."
  10. Click "Yes" when prompted if you wish to proceed.
    FreeOTFE will then write pseudorandom data to the drive, which will then be encrypted before being written to the volume file.

Hiding a Linux Volume Within Another Volume

 To create a Linux volume within another volume file:
  1. Create a FreeOTFE/Linux volume as normal, ensuring that you initialize the volume by mounting it, formatting it, and then overwriting all its free space.
  2. Unmount the "host" volume
  3. Remount the "host" volume, but specify a reasonable offset on the "File options" tab of the Linux mount dialog.

Mounting Volumes Created under Linux

 Select "File | Linux volume | Mount file.../Mount partition".
Enter the volume's password, and set all appropriate options
Click "OK".

Note that if you do not:
  1. Set the same options as used when the volume is mounted and used while under Linux
  2. Format the volume using a filesystem MS Windows understands (i.e. NTFS/FAT/FAT32)
then although your Linux volume may well be mounted, its contents will probably be unreadable.

Cryptoloop Specific

Hash Selection
Cryptoloop ("losetup") Linux volumes use the hash of the user's key as the key used for reading/writing to the encrypted volume.
Cryptoloop and RIPEMD-160
 If you pass "-H rmd160" to losetup in order to use RIPEMD-160 to process your password, losetup's behaviour changes slightly. The user's password is not simply hashed with RIPEMD-160 - instead, the following procedure is used:
  1. The user's password is hashed once using RIPEMD-160
  2. A copy of the first 129 characters of the user's password is made
  3. The capital letter "A" is prepended to the start of the copy
  4. The resulting string is then hashed with RIPEMD-160
  5. This hash is then appended to the first hash to produce 320 bits of data
  6. The appropriate number of bits is taken from the result, and used as the encryption/decryption key.
For this reason, FreeOTFE includes a RIPEMD-160 driver specifically modified ("RIPEMD-160 (Linux; Twice, with A)") to carry out this form of hashing.

(This does not appear to be documented; the above logic was derived from examining "util-linux-2.12p.diff" - one of the files included with loop-AES)

Cypher Selection
 If the cypher selected ("-e" parameter passed as losetup) can support different keysizes (e.g. AES supports 128/192/256 bit keysizes), and the user doesn't specify the keysize to be used (i.e. you specify "-e AES" as opposed to "-e AES128"), then the cypher will default to using 128 bit keys.

(From: http://loop-aes.sourceforge.net/loop-AES.README)

dm-crypt Specific
/dev/loop1 Usage in the Examples Included in this Documentation
The examples shown in this documentation include the slightly odd step of:

losetup /dev/loop1 /dev/mapper/myMapper
mkdosfs /dev/loop1
...

as opposed to just straight:

mkdosfs /dev/mapper/myMapper
...

This is done as, in my tests, the latter appears to result in failure:

# mkdosfs /dev/mapper/myMapper
mkdosfs 2.8 (28 Feb 2001)
mkdosfs: unable to get drive geometry for '/dev/mapper/myMapper'
Hash Selection
 If an attempt is made to mount a volume using a cypher with a larger keysize than the hash algorithm used to processes the user's password, dm-crypt appears to use the following algorithm to generate the actual encryption/decryption key used by the cypher:
  1. The user's password is hashed.
  2. If the hash output contains fewer bits than the cypher's keysize, the capital letter "A" is prepended to the user's password, and a new hash is generated.
  3. This second hash is appended to the previous one
  4. If the total hash output contains fewer bits than the cypher's keysize, another capital letter "A" is prepended to the user's password, and a new hash is generated.
  5. This third hash is appended to the previous hashes
  6. If the total hash output contains fewer bits than the cypher's keysize, another capital letter "A" is prepended to the user's password, and a new hash is generated.
  7. ...and so on, until the required keylength is reached.
i.e. This is the same as Cryptoloop uses for its RIPEMD-160 hashing, but is extended to produce a key of arbitrary length, by adding multiple "A" characters to the password and hashing, until a key of the required length is obtained.

FreeOTFE supports this form of key processing, which can be invoked by selecting the option "Hash with "A"s, if hash output is too short" on the Linux mount dialog.

Note that, under linux, the actual encryption/decryption key can be shown in its hex representation by running "dmsetup table".

For example, if the volume's password is "password1234567890ABC", then:

If AES (256 bit key) is used for encryption/decryption, and the user's password is processed with RIPEMD-160, the actual encryption/decryption key will be:
FAFE56C3BAB4CD216BA02474AC157EA555FA5711
D539285C28A6D8122D9464EE
This is made up as follows:

FAFE56C3BAB4CD216BA02474AC157EA555FA5711
 The first 160 bits are the RIPEMD-160 hash of "password1234567890ABC" 
D539285C28A6D8122D9464EE0AA3C4811DE0D846
 The remaining bits are the first 96 bits taken from the RIPEMD-160 hash of "Apassword1234567890ABC"

If Blowfish (448 bit key) is used for encryption/decryption, and the user's password is processed with MD5, the actual encryption/decryption key will be:
4EAB90A0D00CE0086EB59DA838CC888D
D1270498F52EFFA562872664BB514F8E
2FA054980C9D92542F5801FDF82ADFEA
121E587A4EEBDF3B
This is made up as follows:

4EAB90A0D00CE0086EB59DA838CC888D
 The first 128 bits are the MD5 hash of "password1234567890ABC" 
D1270498F52EFFA562872664BB514F8E
 The next 128 bits are the MD5 hash of "Apassword1234567890ABC" 
2FA054980C9D92542F5801FDF82ADFEA
 The next 128 bits are the MD5 hash of "AApassword1234567890ABC" 
121E587A4EEBDF3BD6CD437A1B2C32A
 The remaining bits are the first 64 bits taken from the MD5 hash of "AAApassword1234567890ABC"

ESSIV
 dm-crypt's ESSIV functionality is available with v2.6.10 and later Linux kernels.

The manner in which Linux uses ESSIV differs from FreeOTFE volumes in how the ESSIV encryption key is generated. Both hash the master encryption/decryption key to generate the key used for ESSIV, however dm-crypt uses the full hash output as the ESSIV key. This means that if you have a dm-crypt volume which is encrypted using 256 bit AES, and specify MD5 as the ESSIV hash, the ESSIV process will actually use AES-128 for creating the "salt" for ESSIV IVs (MD5 generates 128 bit hashes).

It is for this reason, you cannot create a dm-crypt volume under Linux using 256 bit Twofish, and specify SHA-512 as the ESSIV hash; Twofish doesn't support 512 bit keys, and so dm-crypt fails.

LUKS Specific

 As LUKS is based on dm-crypt, please see also the section above relating to dm-setup.

FreeOTFE supports LUKS to v1.1 of the LUKS specification. This is the latest version at time of writing (2nd December 2007)
ESSIV
 FreeOTFE supports LUKS with ESSIV, subject to the condition that the ESSIV hash used generates hashes with the same, or less, bits than the cypher's block size.

Also at time of writing (25th February 2007), the current LUKS implementation of "cryptsetup" only supports the SHA1 hash algorithm, although other hashes may be used for ESSIV.

Because of the way in which dm-crypt operates (see also the "dm-crypt" section on ESSIV, above), LUKS ESSIV doesn't do what you'd probably expect it to do. Specifically, if you have (for example) a Blowfish-448 encrypted volume, and specify cbc-essiv:sha256 for use as IVs - LUKS (dm-crypt) will actually use Blowfish-256 as the ESSIV cypher, and not Blowfish-448. In other words, the ESSIV cypher used will be from the same "family" of cypher (AES, Blowfish, Serpent, etc) - but will use the keylength which matches the ESSIV hash output length.

As a result of this, another option appears on the LUKS password entry dialog; "Base IV cypher on hash length". If this is checked, then when mounting an ESSIV volume, the keylength of the cypher used for ESSIV generation will be that of the ESSIV hash. If this is unchecked, the ESSIV cypher used will have the same keylength as the main bulk encryption cypher used for securing the encrypted disk image.

Most users will want this option checked.
FreeOTFE Supported LUKS Cyphers
 The following table lists compatibility with LUKS cyphers:

Cypher
 Compatibility
aes
 Supported by FreeOTFE.
twofish
 Supported by FreeOTFE.
serpent
 Supported by FreeOTFE.
cast5
 Supported by FreeOTFE.
cast6
 Supported by FreeOTFE.

FreeOTFE Supported LUKS Cypher modes
 The following table lists compatibility with LUKS cypher modes:

Mode
 Compatibility
ecb
 Not supported by FreeOTFE.
Note: This is a pretty insecure mode - the use of ECB is highly discouraged, and FreeOTFE is unlikely to ever support this mode.
cbc-plain
 Supported by FreeOTFE.
cbc-essiv:<hash>
 Supported by FreeOTFE

FreeOTFE Supported LUKS hashes
 The following table lists compatibility with LUKS hashes:

Hash
 Compatibility
sha1
 Supported by FreeOTFE.
sha256
 Supported by FreeOTFE.
sha512
 Supported by FreeOTFE.
ripemd160
 Supported by FreeOTFE.

Additional Notes on Linux Volumes

 Linux volumes should be formatted as FAT/FAT32/NTFS in order for them to be recognised by MS Windows. Although it should be possible for MS Windows can to understand other filesystems (e.g. ext2/ext3/riserFS), this does require 3rd party filesystem drivers to be installed.

If you do wish to read an ext2/ext3 formatted volume from MS Windows, the filesystem drivers listed below are suggested. There may well be others, though at time of writing (23rd December 2005) these are the only ones that I have checked:

Package
 URL
 Description
Ext2 Installable File System For Windows
 http://www.fs-driver.org/
 Supports both read and write operations with ext2/ext3. Freeware, but closed source.
EXT2 IFS for Windows
 http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm
 Supports ext2, readonly. Open source.


Further information on Linux volumes may be obtained from:

Cryptoloop
 Cryptoloop HOWTO
loop-AES
 loop-AES README
dm-crypt
 dm-crypt WWW site
dm-crypt Wiki
LUKS
 LUKS - Linux Unified Key Setup

Note that for many of the controls on FreeOTFE's Linux mount volume dialog, the equivalent Cryptoloop ("losetup") parameter for that control is displayed in brackets.